Historically, newsgroup applications and email applications have been separate applications. Attempts to integrate the two applications have been cumbersome at best. Early newsgroup applications may have relied on a standalone component like an NNTP (network news transport protocol) client to interact with other newsgroup applications and users. Early email applications may similarly have relied on a separate component like an SMTP (Simple Mail Transport Protocol) client to interact with other email applications and users via SMTP. These two types of applications typically had their own data stores and their own data storage schema.
As the World Wide Web developed, newsgroups became widely accessible through web browsers. These web-based newsgroups facilitated posting messages, reading messages, following threads, and so on. Users became comfortable with the web-based interface to newsgroups and the threading associated with discussions. However, newsgroups still remained separate and distinct from email applications. For example, email was still typically used for more personal communications while newsgroups were typically used for more group-oriented communications. In an early attempt to bridge between the two application types, a newsgroup application may have been configured to send an email notification to an email application when a message was posted to a thread in a discussion forum in which a user was interested. However in these minimally integrated systems it may have been difficult, if possible at all, to participate in a discussion forum using an email client.
In a conventional set of systems, a user may have interacted with a discussion forum by posting a message. This message would not automatically be available to an email application. In fact, the email application may not even have been aware of the discussion forum activity. Thus, a conventional system may have sent a notification email to the email application. The notification email may even have included the text of the discussion forum message. The receiving email application would be able to read the message, but no discussion forum type activities were typically possible from the email application.
These types of early integrations essentially duplicated messages and thus doubled the amount of storage used per message. Additionally, a user would be confronted with two “new” messages for each discussion forum message. The user would be presented with a new message in their email application and when the user accessed a discussion forum application the user would be confronted with another “new” message even though the user may have already read the message in an email application. Deleting or responding to two messages for every individual message could easily become burdensome, confusing, and tiring. Additionally, coordinating backup of duplicated messages may have complicated this type of conventional system.
Upon receiving a notification email, a user typically would not have been able to interact with the discussion forum system message through an email application. For example, a user would not be able to reply to a discussion forum message from an email application. Additionally, the user would not be able to follow the series of messages related to the message from an email application. Thus, these loosely integrated systems did not honor the threading information or provide the threaded experience associated with discussion forum messages.